BlockReleaseDestroy

I wonder about the proper way to Block/Release/Destroy modal dialog boxes, which freeze the interface and insist the box be dealt with next.

I've rarely use 'block' and routinely use 'show' for my dialogs. I'm on a quest to improve performance of my code which includes destroying all my dialogs when done, something I have not been doing. Right now I'm working on a Console Dialog that invokes other Dialogs and other Modal dialogs and have been experiencing serious diagnostic exceptions and weird doors locks as if a box was showign, forcing me to abort with Task Manager.

I see that ... 
   o  The action buttons on the Modal Box should 'release' the box if you want it to disappear.  
   o  DXL continues to execute after the 'release' until it ends, presumably to the end of the apply
      function or a call to halt.
   o  Once the 'release' thread ends, code after the 'block' statement is executed.
 
It appears that code should be written such that ...
   o  'hide' does not make much sense for 'block'ed modal dialogs, unless you want to hide
      it while its working, figuring to release it without interruption.
   o  The box should be destroyed and set null only after the block statement, specifically not
      in any of the apply functions and certainly not in any of the callbacks.  Depending on timing 
      I believe DOORS gets confused about resuming after 'block' when the dialog is destroyed
      before hand.
   o  Any custom 'close' function should 'release', but not 'destroy'.

Comments?

Louie

llandale - Thu Jul 01 14:35:59 EDT 2010

Re: BlockReleaseDestroy
Mathias Mamsch - Thu Jul 01 16:42:55 EDT 2010

Hmm ... I always thought it was very easy:

- if I use block, I use release immediately after ... this way DOORS won't lock up
- if I use block, I use destroy since the dialog ressources are not freed automatically, but not from a callback function -> do it somewhere after the block, when you don't need the dialog box anymore.
- if I use show, I just use hide and hope that DOORS will do the cleanup properly for me

Using hide when you use block is very useful: You can block and release a dialog box multiple times (e.g. if you do a check on the input data after the block -> block the box again if the input was not good).

Additionally I think that release will NOT hide the dialog box, but I might be wrong there -> I think if you use an OK button, a CANCEL button or the default close button, then the dialog will be removed from screen after clicking those buttons. Otherwise it will stay open and you need to remove it manually.

Did not try it so I might be wrong with this.

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: BlockReleaseDestroy
llandale - Fri Jul 02 15:04:48 EDT 2010

Mathias Mamsch - Thu Jul 01 16:42:55 EDT 2010
Hmm ... I always thought it was very easy:

- if I use block, I use release immediately after ... this way DOORS won't lock up
- if I use block, I use destroy since the dialog ressources are not freed automatically, but not from a callback function -> do it somewhere after the block, when you don't need the dialog box anymore.
- if I use show, I just use hide and hope that DOORS will do the cleanup properly for me

Using hide when you use block is very useful: You can block and release a dialog box multiple times (e.g. if you do a check on the input data after the block -> block the box again if the input was not good).

Additionally I think that release will NOT hide the dialog box, but I might be wrong there -> I think if you use an OK button, a CANCEL button or the default close button, then the dialog will be removed from screen after clicking those buttons. Otherwise it will stay open and you need to remove it manually.

Did not try it so I might be wrong with this.

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

This appears to be a reasonble structure for blocking a dialog which has input that must be validated before processing can continue and the dialog hidden. If input on the dialog isn't validated, the dialog is blocked again. When Prompted, you can decide if the input is validated or not.

Run the dialog and DoIt a couple times.

DoneOnce is used to demonstrate that the native 'close' button only 'releases', it does not 'destroy'. Run the dialog and close which will trigger the 'setting DoneOnce' print statment, and notice the dialog can indeed be blocked again.

DB    db
bool    InputOK         = true,
        DoneOnce        = false
 
 
void    applyDoIt(DB dbXX)
{
        InputOK = confirm("[confirm] if Input is OK, [cance] to prompt dialog again")
        release(db)
        print InputOK "\tin DoIt\n"
}
 
void    MakeDialog()
{
        db      = create("Block")
        apply(db, "DoIt", applyDoIt)
        realize(db, 50, 50)
        InputOK = false
        DoneOnce        = false
        while(! InputOK or !DoneOnce)
        {  InputOK = true     // lets native 'close' button cancel
           block(db)
                print "after Block\n"
           if (InputOK and !DoneOnce)
           {  InputOK = false
              DoneOnce  = true
                print "setting DoneOnce\n"
           }
        }
        print "after loop\n"
        destroy(db)
}
 
MakeDialog()

Changing my mind in the middle of this post: deleting DoneOnce and adding a cleaner notion of 'Closed', it looks like this:

DB    db
bool    InputOK = true,
        Closed  = false
 
void    applyDoIt(DB dbXX)
{
        InputOK = confirm("[confirm] if Input is OK, [cance] to prompt dialog again")
        Closed  = false         // No, this is not the 'close' button
        release(db)
        print InputOK "\tin DoIt\n"
}
 
void    MakeDialog()
{
        db      = create("Block")
        apply(db, "DoIt", applyDoIt)
        realize(db, 50, 50)
        InputOK = false
        Closed  = false
        while(! InputOK and ! Closed)
        {  Closed = true     // lets native 'close' button cancel
           block(db)
                print "after Block\n"
        }
        print "after loop\n"
        destroy(db)
}
 
MakeDialog()

Louie

Re: BlockReleaseDestroy
Mathias Mamsch - Sat Jul 03 04:51:38 EDT 2010

llandale - Fri Jul 02 15:04:48 EDT 2010

DB    db
bool    InputOK         = true,
        DoneOnce        = false
 
 
void    applyDoIt(DB dbXX)
{
        InputOK = confirm("[confirm] if Input is OK, [cance] to prompt dialog again")
        release(db)
        print InputOK "\tin DoIt\n"
}
 
void    MakeDialog()
{
        db      = create("Block")
        apply(db, "DoIt", applyDoIt)
        realize(db, 50, 50)
        InputOK = false
        DoneOnce        = false
        while(! InputOK or !DoneOnce)
        {  InputOK = true     // lets native 'close' button cancel
           block(db)
                print "after Block\n"
           if (InputOK and !DoneOnce)
           {  InputOK = false
              DoneOnce  = true
                print "setting DoneOnce\n"
           }
        }
        print "after loop\n"
        destroy(db)
}
 
MakeDialog()

Changing my mind in the middle of this post: deleting DoneOnce and adding a cleaner notion of 'Closed', it looks like this:

DB    db
bool    InputOK = true,
        Closed  = false
 
void    applyDoIt(DB dbXX)
{
        InputOK = confirm("[confirm] if Input is OK, [cance] to prompt dialog again")
        Closed  = false         // No, this is not the 'close' button
        release(db)
        print InputOK "\tin DoIt\n"
}
 
void    MakeDialog()
{
        db      = create("Block")
        apply(db, "DoIt", applyDoIt)
        realize(db, 50, 50)
        InputOK = false
        Closed  = false
        while(! InputOK and ! Closed)
        {  Closed = true     // lets native 'close' button cancel
           block(db)
                print "after Block\n"
        }
        print "after loop\n"
        destroy(db)
}
 
MakeDialog()

Louie

I don't like the idea of doing the input check in the apply function. This forces me to declare the DBE variables globally.

I usually do something like this, but I have no idea on how to handle the pressing of the close button without the use of global variables.

Do you have an idea?

Regards, Mathias

void makeMyDialog () {
   DB diag = create "temporary dialog"
   DBE ed = text (...) 
   DBE rb = choice (...) 
   
   string s 
   int nr
 
   while (1) {
      block diag 
      release diag 
      
      s = get ed
      nr = get rb
      if (variables are ok) {
          destroy diag
          break
      }
 
      ack "Please do it again!"
   }
   
}

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: BlockReleaseDestroy
llandale - Wed Jul 07 16:00:17 EDT 2010

Mathias Mamsch - Sat Jul 03 04:51:38 EDT 2010

void makeMyDialog () {
   DB diag = create "temporary dialog"
   DBE ed = text (...) 
   DBE rb = choice (...) 
   
   string s 
   int nr
 
   while (1) {
      block diag 
      release diag 
      
      s = get ed
      nr = get rb
      if (variables are ok) {
          destroy diag
          break
      }
 
      ack "Please do it again!"
   }
   
}

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Found out right away you must declare the bulk of the DBEs globally; how else can the apply functions read the values and use them? Thus, I routinely declare all the DB and DBE variables together globally, even those few that don't need to be. I guess this really isn't true for 'block'ed dialogs, but as I said I rarely use them.

The 'close' apply function takes the DB as a parameter. You can 'hide' it but setting it to null will not change the actual variable.